home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-bgp-bgp4ospf-interact-00.txt < prev    next >
Text File  |  1993-03-03  |  42KB  |  1,069 lines
  1.  
  2.  
  3.  
  4. Network Working Group                                       K.  Varadhan
  5. Request for Comments: DRAFT                                       OARnet
  6.                                                       September 15, 1992
  7.  
  8.                          BGP4 OSPF Interaction
  9.  
  10.  
  11. Table of Contents
  12.  
  13.  1.  Introduction ....................................................  1
  14.  2.  Reachability Information Exchange ...............................  3
  15.  2.1.  Exporting OSPF information into BGP ...........................  3
  16.  2.2.  Importing BGP information into OSPF ...........................  4
  17.  3.  BGP Identifier and OSPF router ID ...............................  5
  18.  4.  Setting OSPF tags, BGP ORIGIN and AS_PATH attributes ............  6
  19.  4.1.  Semantics of the characteristics bits .........................  8
  20.  4.2.  Configuration parameters for setting the OSPF tag .............  9
  21.  4.3.  Manually configured tags ...................................... 10
  22.  4.4.  Automatically generated tags .................................. 11
  23.  4.4.1. Destinations with incomplete path information, PathLength =0 . 11
  24.  4.4.2. Destinations with incomplete path information, PathLength =1 . 11
  25.  4.4.3. Destinations with incomplete path information, PathLength >=1  12
  26.  4.4.4. Destinations with complete path information, PathLength =0 ... 12
  27.  4.4.5. Destinations with complete path information, PathLength =1 ... 13
  28.  4.4.6. Destinations with complete path information, PathLength >=1 .. 14
  29.  4.5.  Miscellaneous tag settings .................................... 14
  30.  4.6.  Summary of the TagType field setting .......................... 15
  31.  5.  Setting OSPF Forwarding Address and BGP NEXT_HOP attribute ...... 15
  32.  6.  Changes from the BGP 3 - OSPF interactions document ............. 16
  33.  7.  Security Considerations ......................................... 17
  34.  8.  Acknowledgements ................................................ 17
  35.  9.  Bibliography .................................................... 17
  36.  10.  Author's Address ............................................... 18
  37.  
  38. Status of this Memo
  39.  
  40.    This document is an Internet Draft.  Internet Drafts are working
  41.    documents of the Internet Engineering Task Force (IETF), its Areas,
  42.    and its Working Groups.  Note that other groups may also distribute
  43.    working documents as Internet Drafts.
  44.  
  45.    Internet Drafts are draft documents valid for a maximum of six
  46.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  47.    other documents at any time.  It is not appropriate to use Internet
  48.    Drafts as reference material or to cite them other than as a
  49.    ``working draft'' or ``work in progress.''
  50.  
  51.    Please check the I-D abstract listing contained in each Internet
  52.  
  53.  
  54.  
  55. Varadhan                                                        [Page 1]
  56.  
  57. INTERNET DRAFT  (Expires March 15, 1993)                    September 92
  58.  
  59.  
  60.    Draft directory to learn the current status of this or any other
  61.    Internet Draft.
  62.  
  63. Abstract
  64.  
  65.    This memo defines the various criteria to be used when designing an
  66.    Autonomous System Border Routers (ASBR) that will run BGP4 with other
  67.    ASBRs external to the AS and OSPF as its IGP.
  68.  
  69. 1.  Introduction
  70.  
  71.    This document defines the various criteria to be used when designing
  72.    an Autonomous System Border Routers (ASBR) that will run BGP4[BGP-4]
  73.    with other ASBRs external to the AS, and OSPF[RFC1247] as its IGP.
  74.  
  75.    All future references of BGP in this document will refer to BGP
  76.    version 4, as defined in [BGP-4].
  77.  
  78.    This document defines how the following fields in OSPF and attributes
  79.    in BGP are to be set when interfacing between BGP and OSPF at an
  80.    ASBR:
  81.  
  82.            BGP MULTI_EXIT_DISC     vs. OSPF cost and type
  83.            BGP ORIGIN and AS_PATH  vs. OSPF tag
  84.            BGP NEXT_HOP            vs. OSPF Forwarding Address
  85.            BGP LOCAL_PREF          vs. OSPF cost
  86.  
  87.    For a more general treatise on routing and route exchange problems,
  88.    please refer to [ROUTE-LEAKING] and [NEXT-HOP] by Philip Almquist.
  89.  
  90.    This document uses the two terms ``Autonomous System'' and ``Routing
  91.    Domain.'' The definitions for the two are below:
  92.  
  93.    The term Autonomous System is the same as is used in the BGP
  94.    RFC[RFC1267], given below:
  95.  
  96.         ``The use of the term Autonomous System here stresses the fact
  97.         that, even when multiple IGPs and metrics are used, the
  98.         administration of an AS appears to other ASs to have a single
  99.         coherent interior routing plan and presents a consistent picture
  100.         of what destinations are reachable through it.  From the
  101.         standpoint of exterior routing, an AS can be viewed as
  102.         monolithic: reachability to destinations directly connected to
  103.         the AS must be equivalent from all border gateways of the AS.''
  104.  
  105.    The term Routing Domain was first used in [ROUTE-LEAKING] and is
  106.    given below:
  107.  
  108.  
  109.  
  110.  
  111. Varadhan                                                        [Page 2]
  112.  
  113. INTERNET DRAFT  (Expires March 15, 1993)                    September 92
  114.  
  115.  
  116.           ``A Routing Domain is a collection of routers which coordinate
  117.           their routing knowledge using a single (instance of) a routing
  118.           protocol.''
  119.  
  120.      By definition, a Routing Domain forms a single Autonomous System,
  121.      but an Autonomous System may be composed of a collection of Routing
  122.      Domains.
  123.  
  124.      BGP and OSPF have the concept of a set of reachable destinations.    |
  125.      This set is called NLRI or Network Layer Reachability Information.   |
  126.      The set can be represented either as an IP address prefix, or an     |
  127.      address, mask pair.  Note that if the mask is contiguous in the      |
  128.      latter, then the two representations are equivalent.  In this        |
  129.      document, we use the term ``address/mask pair'' in the context of    |
  130.      OSPF, and ``destination'' or ``set of reachable destinations'' in    |
  131.      the context of BGP.
  132.  
  133.      This document follows the conventions embodied in the Host
  134.      Requirements RFCs [RFC1122, RFC1123], when using the terms "MUST",
  135.      "SHOULD," and "MAY" for the various requirements.
  136.  
  137. 2.  Reachability Information Exchange
  138.  
  139.    This section discusses the constraints that must be met to exchange
  140.    the set of reachable destinations between an external BGP session
  141.    with a peer from another AS and internal OSPF address/mask pairs.
  142.  
  143.    2.1.  Exporting OSPF information into BGP
  144.  
  145.  
  146.       1.   The administrator MUST be able to selectively export           |
  147.            address/mask pairs into BGP via an appropriate filter          |
  148.            mechanism.                                                     |
  149.  
  150.            This filter mechanism MUST support such control with the       |
  151.            granularity of an address/mask pair.                           |
  152.  
  153.            This filter mechanism will be the primary method of            |
  154.            aggregation of OSPF internal and type 1 and type 2 external    |
  155.            routes within the AS into BGP.                                 |
  156.  
  157.            Additionally, the administrator MUST be able to filter based
  158.            on the OSPF tag and the various sub-fields of the OSPF tag.
  159.            The settings of the tag and the sub-fields are defined in
  160.            section 4 in more detail.
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167. Varadhan                                                        [Page 3]
  168.  
  169. INTERNET DRAFT  (Expires March 15, 1993)                    September 92
  170.  
  171.  
  172.            o    The default MUST be to export no routes from OSPF into
  173.                 BGP.  A single configuration parameter MUST permit all
  174.                 OSPF inter-area and intra-area address/mask pairs to be
  175.                 exported into BGP.
  176.  
  177.                 OSPF external address/mask pairs of type 1 and type 2
  178.                 MUST never be exported into BGP unless they are
  179.                 explicitly configured.
  180.  
  181.       2.   An address/mask pair having a non-contiguous mask MUST not be  |
  182.            exported to BGP.                                               |
  183.  
  184.       3.   When configured to export an address/mask pair from OSPF into  |
  185.            BGP, the ASBR MAY advertise the route containing the set of    |
  186.            reachable destinations via BGP as soon as at least one of the  |
  187.            destinations in the address/mask pair is determined to be      |
  188.            reachable via OSPF;  it MUST stop advertising the route        |
  189.            containing the set of reachable destinations when none of the  |
  190.            destinations in the address/mask pair is reachable via OSPF.   |
  191.  
  192.       4.   The network administrator MUST be able to statically           |
  193.            configure the BGP attribute MULTI_EXIT_DISC attribute to be    |
  194.            used for any route.                                            |
  195.  
  196.            o    The default MUST be to omit the MULTI_EXIT_DISC in the    |
  197.                 route advertised via BGP[BGP-4].                          |
  198.  
  199.       5.   An implementation of BGP and OSPF on an ASBR MUST have a
  200.            mechanism to set up a minimum amount of time that must elapse
  201.            between the learning of a new address/mask pair via OSPF and
  202.            subsequent advertisement of the address/mask pair via BGP to
  203.            the external neighbours.
  204.  
  205.            o    The default value for this setting MUST be 0, indicating
  206.                 that the address/mask pair is to be advertised to the
  207.                 neighbour BGP peers instantly.
  208.  
  209.                 Note that [BGP-4] mandates a mechanism to dampen the
  210.                 inbound advertisements from adjacent neighbours.  See
  211.                 the variable MinRouteAdvertisementInterval in section
  212.                 9.2.3.1.
  213.  
  214.    2.2.  Importing BGP information into OSPF
  215.  
  216.       1.   BGP implementations SHOULD allow an AS to control
  217.            announcements of BGP-learned set of reachable destinations
  218.            into OSPF.  Implementations SHOULD support such control with
  219.            the granularity of a single destination.  Implementations
  220.  
  221.  
  222.  
  223. Varadhan                                                        [Page 4]
  224.  
  225. INTERNET DRAFT  (Expires March 15, 1993)                    September 92
  226.  
  227.  
  228.            SHOULD also support such control with the granularity of an
  229.            autonomous system, where the autonomous system may be either
  230.            the autonomous system that originated the information or the
  231.            autonomous system that advertised the information to the
  232.            local system (adjacent autonomous system).
  233.  
  234.            o    The default MUST be to import nothing from BGP into
  235.                 OSPF.  Administrators must configure every destination
  236.                 they wish to import.
  237.  
  238.                 A configuration parameter MAY allow an administrator to
  239.                 configure an ASBR to import all the set of reachable
  240.                 destinations from BGP into the OSPF routing domain.
  241.  
  242.       2.   The administrator MUST be able to configure the OSPF cost and
  243.            the OSPF metric type of every destination imported into OSPF.
  244.  
  245.            o    The OSPF cost MUST default to the LOCAL_PREF value; the   |
  246.                 OSPF metric type MUST default to type 2.                  |
  247.  
  248.       3.   Information learned via BGP from peers within the same AS
  249.            MUST not be imported into OSPF.
  250.  
  251.       4.   The ASBR MUST never generate a default destination into the
  252.            OSPF routing domain unless explicitly configured to do so.
  253.  
  254.            A default destination is a set of all possible destinations.
  255.            By convention, it is represented as a prefix 0 length or a
  256.            mask of all zeroes.
  257.  
  258.            A possible criterion for generating default into an IGP is to
  259.            allow the administrator to specify a set of (set of reachable
  260.            destinations, AS_PATH, default cost, default type) tuples.
  261.            If the ASBR learns of at least one of the destinations in the
  262.            set of reachable destinations, with the corresponding
  263.            AS_PATH, then it generates a default destination into the
  264.            OSPF routing domain, with the appropriate cost and type.  The
  265.            lowest cost route will then be injected into the OSPF routing
  266.            domain.
  267.  
  268.            This is the recommended method for originating default
  269.            destinations in the OSPF routing domain.                       |
  270.  
  271.       5.   Note that [RFC1247] requires the network number to be used as  |
  272.            the Link State ID.  This will produce a conflict if the ASBR   |
  273.            tries to import two destinations, differing only in their      |
  274.            prefix length.  An implementation conforming to [RFC1247]      |
  275.            MUST, in this case, drop the more specific route, i.e. the     |
  276.  
  277.  
  278.  
  279. Varadhan                                                        [Page 5]
  280.  
  281. INTERNET DRAFT  (Expires March 15, 1993)                    September 92
  282.  
  283.  
  284.            route corresponding to the longer prefix in the reachability   |
  285.            information.                                                   |
  286.  
  287.            Note that the OSPF WG is working on revising [RFC1247].  The   |
  288.            revised version will incorporate hooks to handle the           |
  289.            conflict.
  290.  
  291. 3.  BGP Identifier and OSPF router ID
  292.  
  293.    The BGP identifier MUST be the same as the OSPF router id at all
  294.    times that the router is up.  Note that [BGP-4] requires that the BGP  |
  295.    identifier be an address assigned to the BGP speaker.
  296.  
  297.    This characteristic is required for two reasons.
  298.  
  299.      i    Consider the scenario in which 3 ASBRs, RT1, RT2, and RT3,
  300.           belong to the same autonomous system.
  301.  
  302.  
  303.                                      +-----+
  304.                                      | RT3 |
  305.                                      +-----+
  306.                                         |
  307.  
  308.                           Autonomous System running OSPF
  309.  
  310.                                  /               \
  311.                              +-----+          +-----+
  312.                              | RT1 |          | RT2 |
  313.                              +-----+          +-----+
  314.  
  315.  
  316.           Both RT1 and RT2 can reach an external destination X and
  317.           import this information into the OSPF routing domain.  RT3 is
  318.           advertising this information about destination X to other
  319.           external BGP speakers.  RT3 must use the OSPF router ID to
  320.           determine whether it is using RT1 or RT2 to forward packets to
  321.           destination X and hence build the correct AS_PATH to advertise
  322.           to other external speakers.
  323.  
  324.           More precisely, RT3 MUST determine which ASBR it is using to    |
  325.           reach destination X by matching the OSPF router ID for its      |
  326.           route to destination X with the BGP identifier of one of the    |
  327.           ASBRs; it MAY then generate the corresponding network layer     |
  328.           reachability information for further advertisement to external  |
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335. Varadhan                                                        [Page 6]
  336.  
  337. INTERNET DRAFT  (Expires March 15, 1993)                    September 92
  338.  
  339.  
  340.           BGP peers.
  341.  
  342.      ii   It will be convenient for the network administrator looking at
  343.           an ASBR to correlate different BGP and OSPF information based
  344.           on the identifier.
  345.  
  346. 4.  Setting OSPF tags, BGP ORIGIN and AS_PATH attributes
  347.  
  348.    The OSPF external route tag is a ``32-bit field attached to each
  349.    external route . . . It may be used to communicate information
  350.    between AS boundary routers; the precise nature of such information
  351.    is outside the scope of [the] specification.''[RFC1247]
  352.  
  353.    OSPF imports information from various routing protocols at all its
  354.    ASBRs.  In some instances, it is possible to use protocols other than
  355.    EGP or BGP across autonomous systems.  It is important, in BGP, to
  356.    differentiate between reachable destinations that are external to the
  357.    OSPF routing domain but must be considered internal to the AS, as
  358.    opposed to reachable destinations that are external to the AS.
  359.  
  360.    Reachable destinations that are internal to the AS and that may or
  361.    may not be external to the OSPF routing domain will not come to the
  362.    various BGP speakers from other BGP speakers within the same
  363.    autonomous system via BGP.  Therefore, ASBRs running BGP must have
  364.    knowledge of this class of reachable destinations so that they can
  365.    advertise these destinations to the various external AS without
  366.    waiting for BGP updates from other BGP speakers within the same
  367.    autonomous system about these destinations.
  368.  
  369.    Additionally, in the specific instance of an AS intermixing routers
  370.    running EGP and BGP as external gateway routing protocols, using OSPF
  371.    as an IGP, then within the autonomous system, it may not be necessary
  372.    to run BGP with every ASBR running EGP and not running BGP, if this
  373.    information can be carried in the OSPF tag field.
  374.  
  375.    We use the external route tag field in OSPF to intelligently set the
  376.    ORIGIN and AS_PATH attributes in BGP.  Both the ORIGIN and AS_PATH
  377.    attributes are well-known, mandatory attributes in BGP.  The exact
  378.    mechanism for setting the tags is defined below.
  379.  
  380.    The tag is broken up into sub-fields shown below.  The various sub-
  381.    fields specify the characteristics of the set of reachable
  382.    destinations imported into the OSPF routing domain.
  383.  
  384.    The high bit of the OSPF tag is known as the ``Automatic'' bit.  When
  385.    this bit is set to 1, the following sub-fields apply:
  386.  
  387.  
  388.  
  389.  
  390.  
  391. Varadhan                                                        [Page 7]
  392.  
  393. INTERNET DRAFT  (Expires March 15, 1993)                    September 92
  394.  
  395.  
  396.  
  397.       0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  398.       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  399.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  400.      |a|c|p l|     ArbitraryTag      |       AutonomousSystem        |
  401.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  402.  
  403.  
  404.      a    is 1 bit called the Automatic bit, indicating that the
  405.           Completeness and PathLength bits have been generated
  406.           automatically by a router.  The meaning of this characteristic
  407.           and its setting are defined below.
  408.  
  409.      c    is 1 bit of Completeness information.  The meaning of this
  410.           characteristic and its settings are defined below.
  411.  
  412.      pl   are 2 bits of PathLength information.  The meaning of this
  413.           characteristic and its setting are defined below.
  414.  
  415.      ArbitraryTag
  416.           is 12 bits of tag information, which defaults to 0 but can be
  417.           configured to anything else.
  418.  
  419.      AutonomousSystem (or ``AS'')
  420.           is 16 bits, indicating the AS number corresponding to the set
  421.           of reachable destinations, 0 if the set of reachable
  422.           destinations is to be considered as part of the local AS.
  423.  
  424.           local_AS
  425.                The term `local_AS' refers to the AS number of the local
  426.                OSPF routing domain.
  427.  
  428.           next_hop_AS
  429.                `next_hop_AS' refers to the AS number of an external BGP
  430.                peer.
  431.  
  432.      When the Automatic bit is set to 0, the following sub-fields apply:
  433.  
  434.       0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  435.       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  436.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  437.      |a|                          LocalInfo                          |
  438.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  439.  
  440.  
  441.      a    is 1 bit called the Automatic bit, set to 0.
  442.  
  443.      LocalInfo
  444.  
  445.  
  446.  
  447. Varadhan                                                        [Page 8]
  448.  
  449. INTERNET DRAFT  (Expires March 15, 1993)                    September 92
  450.  
  451.  
  452.           is 31 bits of an arbitrary value, manually configured by the
  453.           network administrator.
  454.  
  455.      The format of the tag for various values of the characteristics
  456.      bits is defined below.
  457.  
  458.    4.1.  Semantics of the characteristics bits
  459.  
  460.       The Completeness and PathLength characteristics bits define the
  461.       characteristic of the set of reachable destinations imported into
  462.       OSPF from other ASBRs in the autonomous system.  This setting is
  463.       then used to set the ORIGIN and NEXT_HOP attributes when re-
  464.       exporting these reachable destinations to an external BGP speaker.
  465.  
  466.       o    The Automatic characteristic bit is set when the Completeness
  467.            and PathLength characteristics bits are automatically set by
  468.            a border router.
  469.  
  470.            For backward compatibility, the Automatic bit must default to
  471.            0 and the network administrator must have a mechanism to
  472.            enable automatic tag generation.  Nothing must be inferred
  473.            about the characteristics of the OSPF address/mask pair from
  474.            the tag bits, unless the tag has been automatically
  475.            generated.
  476.  
  477.       o    The Completeness characteristic bit is set when the source of
  478.            the incoming route is known precisely, for instance, from an
  479.            IGP within the local autonomous system or EGP at one of the
  480.            autonomous system's boundaries.  It refers to the status of
  481.            the path information carried by the routing protocol.
  482.  
  483.       o    The PathLength characteristic sub-field is set depending on
  484.            the length of the AS_PATH that the protocol could have
  485.            carried when importing the reachability information into the
  486.            OSPF routing domain.  The length bits will indicate whether
  487.            the AS_PATH attribute for the length is zero, one, or greater
  488.            than one.
  489.  
  490.            Reachable destinations imported from an IGP will usually have
  491.            an AS_PATH of length of 0, reachable destinations imported
  492.            from an EGP will have an AS_PATH of length 1, BGP and routing
  493.            protocols that support complete path information, either as
  494.            AS_PATHs or routing domain paths, will indicate a path
  495.            greater than 1.
  496.  
  497.            The OSPF tag is not wide enough to carry path information
  498.            about reachable destinations that have an associated
  499.            PathLength greater than one.  Path information about these
  500.  
  501.  
  502.  
  503. Varadhan                                                        [Page 9]
  504.  
  505. INTERNET DRAFT  (Expires March 15, 1993)                    September 92
  506.  
  507.  
  508.            destinations will have to be carried via BGP to other ASBRs
  509.            with the same autonomous system.  Such destinations must not
  510.            be exported from OSPF into BGP.
  511.  
  512.       In the following sections, the code YES will have value 1, and the  |
  513.       code NO will have value 0.
  514.  
  515.    4.2.  Configuration parameters for setting the OSPF tag
  516.  
  517.       o    There MUST be a mechanism to enable automatic generation of
  518.            the tag characteristic bits.
  519.  
  520.       o    Configuration of an ASBR running OSPF MUST include the
  521.            capability to associate a tag value, for the ArbitraryTag, or
  522.            LocalInfo sub-field of the OSPF tag, with each instance of a
  523.            routing protocol.
  524.  
  525.       o    Configuration of an ASBR running OSPF MUST include the
  526.            capability to associate an AS number with each instance of a
  527.            routing protocol.
  528.  
  529.            Associating an AS number with an instance of an IGP is
  530.            equivalent to flagging those set of reachable destinations
  531.            imported from the IGP to be external destinations outside the
  532.            local autonomous system.
  533.  
  534.            Specifically, when the IGP is RIP[RFC1058], it SHOULD be
  535.            possible to associate a tag and/or an AS number with every
  536.            interface running RIP on the ASBR.
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559. Varadhan                                                       [Page 10]
  560.  
  561. INTERNET DRAFT  (Expires March 15, 1993)                    September 92
  562.  
  563.  
  564.       4.3.  Manually configured tags
  565.  
  566.       0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  567.       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  568.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  569.      |0|                          LocalInfo                          |
  570.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  571.  
  572.          This tag setting  corresponds  to  the  administrator  manually
  573.          setting   the  tag  bits.   Nothing  MUST  inferred  about  the
  574.          characteristics  of   the   set   of   reachable   destinations
  575.          corresponding to this tag setting.
  576.  
  577.          For backward compatibility  with  existing  implementations  of
  578.          OSPF  currently deployed in the field, this MUST be the default
  579.          setting  for  importing  destinations  into  the  OSPF  routing
  580.          domain.   There  MUST  be  a  mechanism to enable automatic tag
  581.          generation for imported destinations.
  582.  
  583.          The OSPF tag to BGP  attribute  mappings  for  these  reachable
  584.          destinations MUST be
  585.  
  586.          Automatic=NO, LocalInfo=Arbitrary_Value =>
  587.                                  ORIGIN=<INCOMPLETE>, AS_PATH=<local_AS>
  588.  
  589.    4.4.  Automatically generated tags
  590.  
  591.       4.4.1. Destinations with incomplete path information, PathLength =
  592.          0
  593.  
  594.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  595.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  596.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  597.       |1|0|0|0|     ArbitraryTag      |       AutonomousSystem        |
  598.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  599.  
  600.          These are reachable destinations imported from routing
  601.          protocols with incomplete path information and cannot or may
  602.          not carry the neighbour AS or AS path as part of the routing
  603.          information.
  604.  
  605.          The OSPF tag to BGP attribute mappings for these destinations
  606.          MUST be
  607.  
  608.          Automatic=YES, Completeness=NO, PathLength=00, AS=0 =>
  609.                                         ORIGIN=<EGP>, AS_PATH=<local_AS>
  610.  
  611.  
  612.  
  613.  
  614.  
  615. Varadhan                                                       [Page 11]
  616.  
  617. INTERNET DRAFT  (Expires March 15, 1993)                    September 92
  618.  
  619.  
  620.       4.4.2. Destinations with incomplete path information, PathLength =
  621.          1
  622.  
  623.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  624.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  625.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  626.       |1|0|0|1|     ArbitraryTag      |       AutonomousSystem        |
  627.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  628.  
  629.          These are reachable destinations imported from routing
  630.          protocols with incomplete path information.  The neighbour AS
  631.          is carried in the routing information.
  632.  
  633.          The OSPF tag to BGP attribute mappings for these destinations
  634.          MUST be
  635.  
  636.          Automatic=YES, Completeness=NO, PathLength=01, AS=<next_hop_AS>
  637.                         => ORIGIN=<EGP>, AS_PATH=<local_AS, next_hop_AS>
  638.  
  639.          This setting SHOULD be used for importing reachable
  640.          destinations from EGP into the OSPF routing domain.  This
  641.          setting MAY also be used when importing reachable destinations
  642.          from BGP whose origin=<EGP> and AS_PATH=<next_hop_AS>;  if the
  643.          BGP learned route has no other transitive attributes, then its
  644.          propagation via BGP to ASBRs internal to the autonomous system
  645.          MAY be suppressed.
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671. Varadhan                                                       [Page 12]
  672.  
  673. INTERNET DRAFT  (Expires March 15, 1993)                    September 92
  674.  
  675.  
  676.       4.4.3. Destinations with incomplete path information, PathLength
  677.          >= 1
  678.  
  679.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  680.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  681.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  682.       |1|0|1|0|     ArbitraryTag      |       AutonomousSystem        |
  683.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  684.  
  685.          These are reachable destinations imported from routing
  686.          protocols with truncated path information.
  687.  
  688.          The OSPF tag to BGP attribute mappings for these destinations
  689.          MUST be
  690.  
  691.          Automatic=YES, Completeness=NO, PathLength=10, AS=don't care
  692.  
  693.          These are imported by a border router, which is running BGP to
  694.          a stub domain, and not running BGP to other ASBRs in the same
  695.          autonomous system.  This causes a truncation of the AS_PATH.
  696.          These destinations MUST not be re-exported into BGP at another
  697.          ASBR.
  698.  
  699.       4.4.4. Destinations with complete path information, PathLength = 0
  700.  
  701.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  702.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  703.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  704.       |1|1|0|0|     ArbitraryTag      |       AutonomousSystem        |
  705.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  706.  
  707.          These are reachable destinations imported from routing
  708.          protocols with either complete path information or are known to
  709.          be complete through means other than that carried by the
  710.          routing protocol.
  711.  
  712.          The OSPF tag to BGP attribute mappings for these destinations
  713.          MUST be
  714.  
  715.          Automatic=YES, Completeness=YES, PathLength=00, AS=00
  716.                                      => ORIGIN=<EGP>, AS_PATH=<local_AS>
  717.  
  718.          This SHOULD be used for importing reachable destinations into
  719.          OSPF from an IGP.
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727. Varadhan                                                       [Page 13]
  728.  
  729. INTERNET DRAFT  (Expires March 15, 1993)                    September 92
  730.  
  731.  
  732.       4.4.5. Destinations with complete path information, PathLength = 1
  733.  
  734.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  735.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  736.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  737.       |1|1|0|1|     ArbitraryTag      |       AutonomousSystem        |
  738.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  739.  
  740.          These are reachable destinations imported from routing
  741.          protocols with either complete path information, or are known
  742.          to be complete through means other than that carried by the
  743.          routing protocol.  The routing protocol also has additional
  744.          information about the next hop AS the destination was learned
  745.          from.
  746.  
  747.          The OSPF tag to BGP attribute mappings for these destination
  748.          MUST be
  749.  
  750.          Automatic=YES, Completeness=YES, PathLength=01, AS=next_hop_AS
  751.                         => ORIGIN=<IGP>, AS_PATH=<local_AS, next_hop_AS>
  752.  
  753.          This setting SHOULD be used when the administrator explicitly
  754.          associates an AS number with an instance of an IGP.  This
  755.          setting MAY also be used when importing reachable destinations
  756.          from BGP whose origin=<IGP> and AS_PATH=<next_hop_AS>;  if the
  757.          BGP learned route has no other transitive attributes, then its
  758.          propagation via BGP to other ASBRs internal to the autonomous
  759.          system MAY be suppressed.
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783. Varadhan                                                       [Page 14]
  784.  
  785. INTERNET DRAFT  (Expires March 15, 1993)                    September 92
  786.  
  787.  
  788.       4.4.6. Destinations with complete path information, PathLength >=1
  789.  
  790.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  791.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  792.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  793.       |1|1|1|0|     ArbitraryTag      |       AutonomousSystem        |
  794.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  795.  
  796.          These are reachable destinations imported from routing
  797.          protocols with complete path information and carry the AS path
  798.          information as part of the routing information.
  799.  
  800.          The OSPF tag MUST be set to
  801.  
  802.          Automatic=YES, Completeness=YES, PathLength=10, AS=don't care
  803.  
  804.          These destinations MUST not be exported into BGP because these
  805.          destinations are already imported from BGP into the OSPF RD.
  806.          Hence, it is assumed that the BGP speaker will convey this
  807.          information to other BGP speakers within the same autonomous
  808.          system via BGP.  As ASBR learning of such a destination MUST
  809.          wait for the BGP update from its internal neighbours before
  810.          advertising it to external BGP peers.
  811.  
  812.          Note that an implementation MAY import reachable destinations
  813.          from BGP with a path length of 1 and no other transitive
  814.          attributes directly into OSPF and not send these routes via BGP
  815.          to ASBRs within the same autonomous system.  In this situation,
  816.          it MUST use tag settings corresponding to 4.4.2, or 4.4.5.
  817.  
  818.    4.5.  Miscellaneous tag settings
  819.  
  820.       0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0
  821.       1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  822.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  823.      |1|x|1|1|              Reserved  for  future  use               |
  824.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  825.  
  826.       The value of PathLength=11 is reserved during automatic tag
  827.       generation.  Routers must not generate such a tag when importing
  828.       reachable destinations into the OSPF routing domain.  ASBRs must
  829.       ignore tags which indicate a PathLength=11.
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839. Varadhan                                                       [Page 15]
  840.  
  841. INTERNET DRAFT  (Expires March 15, 1993)                    September 92
  842.  
  843.  
  844.    4.6.  Summary of the tag sub-field setting
  845.  
  846.       The following table summarizes the various combinations of
  847.       automatic tag settings for the Completeness and PathLength sub-
  848.       field of the OSPF tag and the default behaviour permitted for each
  849.       setting.
  850.  
  851.                   Completeness := 0 | 1
  852.                   PathLength := 00 | 01 | 10 | 1
  853.                   ORIGIN := <INCOMPLETE> | <IGP> | <EGP>
  854.                   AS_PATH := valid AS path settings as defined in BGP [BGP-4]
  855.  
  856. PathLength ==> 00               01                   10                11
  857. Completeness
  858.   ||     +--------------------------------------------------------------------
  859.   vv     |
  860.   =  NO  |    <EGP>            <EGP>             never export       reserved
  861.          |  <local_AS>  <local_AS,next_hop_AS>
  862.          |
  863.   = YES  |    <IGP>            <IGP>             out of band        reserved
  864.          |  <local_AS>  <local_AS,next_hop_AS>
  865.          |
  866.  
  867.       The "out of band" in the table above implies that OSPF will not be
  868.       able to carry everything that BGP needs in its routing
  869.       information.  Therefore, some other means must be found to carry
  870.       this information.  In BGP, this is done by running BGP to other
  871.       ASBRs within the same autonomous system.
  872.  
  873. 5.  Setting OSPF Forwarding Address and BGP NEXT_HOP attribute
  874.  
  875.    Forwarding addresses are used to avoid extra hops between multiple
  876.    routers that share a common network and that speak different routing
  877.    protocols with each other on the common network.                       |
  878.  
  879.    Both BGP and OSPF have equivalents of forwarding addresses.  In BGP,
  880.    the NEXT_HOP attribute is a well-known, mandatory attribute.  OSPF
  881.    has a Forwarding address field.  We will discuss how these are to be
  882.    filled in various situations.
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895. Varadhan                                                       [Page 16]
  896.  
  897. INTERNET DRAFT  (Expires March 15, 1993)                    September 92
  898.  
  899.  
  900.  
  901.    Consider the 4 router situation below:
  902.  
  903.    RT1 and RT2 are in one autonomous system, RT3 and RT4 are in another.
  904.    RT1 and RT3 are talking BGP with each other.
  905.    RT3 and RT4 are talking OSPF with each other.
  906.  
  907.             +-----+                 +-----+
  908.             | RT1 |                 | RT2 |
  909.             +-----+                 +-----+
  910.                |                       |            common network
  911.             ---+-----------------------+--------------------------
  912.                  <BGP> |                       |
  913.                     +-----+     <OSPF>      +-----+
  914.                     | RT3 |                 | RT4 |
  915.                     +-----+                 +-----+
  916.  
  917.  
  918.      - Importing a reachable destination into OSPF:                       |
  919.           When importing a destination from BGP into OSPF, RT3 MUST       |
  920.           always fill the OSPF Forwarding Address with the BGP NEXT_HOP   |
  921.           attribute for the destination.                                  |
  922.  
  923.      - Exporting a reachable destination into BGP:                        |
  924.           When exporting set of reachable destinations internal to the    |
  925.           OSPF routing domain from OSPF to BGP, if all the destinations   |
  926.           in the set of reachable destinations are through RT4, then RT3  |
  927.           MAY fill the NEXT_HOP attribute for the set of reachable        |
  928.           destinations with the address of RT4.  This is to avoid         |
  929.           requiring packets to take an extra hop through RT3 when         |
  930.           traversing the AS boundary.  This is similar to the concept of  |
  931.           indirect neighbour support in EGP[RFC888, RFC827].              |
  932.  
  933. 6.  Changes from the BGP 3 - OSPF interactions document                   |
  934.  
  935.      o    The use of the term "route" has attained a more complicated     |
  936.           structure in BGP 4.  This document follows the constraint in    |
  937.           the manner shown below:                                         |
  938.  
  939.           -    The term "set of reachable destinations" is called a NLRI  |
  940.                in [BGP-4].                                                |
  941.  
  942.           -    The term "route" in the BGP context refers to a set of     |
  943.                reachable destinations, and the associated attributes for  |
  944.                the set.                                                   |
  945.  
  946.           -    The term "route" in the OSPF context refers to the set of  |
  947.                reachable destinations, and the cost and the type to       |
  948.  
  949.  
  950.  
  951. Varadhan                                                       [Page 17]
  952.  
  953. INTERNET DRAFT  (Expires March 15, 1993)                    September 92
  954.  
  955.  
  956.                reach destinations.  This is to keep the definitions       |
  957.                consistent in the document.                                |
  958.  
  959.      o    The notion of exchanging reachability information between BGP   |
  960.           4 and OSPF has been updated to handle variable length net mask  |
  961.           information.                                                    |
  962.  
  963.      o    The previous term INTER_AS_METRIC in BGP 3 has now been         |
  964.           changed to MULTI_EXIT_DISC.                                     |
  965.  
  966.      o    The default metric to be used for importing BGP information     |
  967.           into the OSPF RD is now the LOCAL_PREF attribute, instead of a  |
  968.           constant value.                                                 |
  969.  
  970.      o    BGP 4 requires that the BGP identifier be an address assigned   |
  971.           to the BGP speaker.  This is dealt with in section 3.           |
  972.  
  973.      o    Section 5 on setting NEXT_HOP attributes and Forwarding         |
  974.           Address fields has been updated to account for variable length  |
  975.           net information.                                                |
  976.  
  977.      o    This section, 6, has been added.                                |
  978.  
  979. 7.  Security Considerations
  980.  
  981.    Security considerations are not discussed in this memo.
  982.  
  983. 8.  Acknowledgements
  984.  
  985.    I would like to thank Yakov Rekhter (IBM Corporation), Jeff Honig
  986.    (Cornell University), John Moy (Proteon, Inc.), Tony Li (cisco
  987.    Systems), Rob Coltun (Consultant), Dennis Ferguson (ANS, Inc.), and
  988.    Phil Almquist (Consultant) for their help and suggestions in writing
  989.    this document, without which I could not have written this document.
  990.    I would also like to thank them for giving me the opportunity to
  991.    write this document, and putting up with my muddlements through
  992.    various phases of this document.
  993.  
  994.    I would also like to thank the countless number of people from the
  995.    OSPF and BGP working groups who have offered numerous suggestions and
  996.    comments on the different stages of this document.
  997.  
  998.    Thanks also to Bob Braden (ISI), whose suggestions on the earlier
  999.    BGP-OSPF document, [RFC1364] were useful even for this one, and have
  1000.    been carried through.
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007. Varadhan                                                       [Page 18]
  1008.  
  1009. INTERNET DRAFT  (Expires March 15, 1993)                    September 92
  1010.  
  1011.  
  1012. 9.  Bibliography
  1013.  
  1014.  
  1015. [RFC827]   Rosen, Eric C., ``Exterior Gateway Protocol (EGP)'', October
  1016.      1982.
  1017.  
  1018. [RFC888]   Seamonson, Linda J.; and Rosen, Eric C., ``'STUB' Exterior
  1019.      Gateway Protocol'', January 1984.
  1020.  
  1021. [RFC1058]  Hedrick, Charles, L., ``Routing Information Protocol'', June
  1022.      1988.
  1023.  
  1024. [RFC1122]  Braden, R.T., ed., ``Requirements for Internet hosts -
  1025.      communication layers'', October 1989.
  1026.  
  1027. [RFC1123]  Braden, R.T., ed., ``Requirements for Internet hosts -
  1028.      application and support'', October 1989.
  1029.  
  1030. [RFC1247]  Moy, John, ``The OSPF Specification  Version 2'', January
  1031.      1991.
  1032.  
  1033. [RFC1338]  Fuller, Vince; Li, Tony; Yu, Jessica; Varadhan, Kannan,
  1034.      ``Supernetting: an Address Assignment and Aggregation Strategy'',
  1035.      June 1992.
  1036.  
  1037. [ROUTE-LEAKING]  Almquist, Philip, ``Ruminations on Route Leaking'', in
  1038.      preparation.
  1039.  
  1040. [NEXT-HOP]  Almquist, Philip, ``Ruminations on the Next Hop'', in
  1041.      preparation.
  1042.  
  1043. [BGP-4]  Rekhter, Yakov; and Li, Tony, Editors ``A Border Gateway
  1044.      Protocol 4 (BGP-4)'', in preparation.
  1045.  
  1046. [RFC1364] Varadhan, Kannan; ``BGP OSPF Interaction'', in preparation.
  1047.  
  1048. 10.  Author's  Address:
  1049.  
  1050.       Kannan Varadhan
  1051.       Internet Engineer, OARnet,
  1052.       1224, Kinnear Road,
  1053.       Columbus, OH 43212-1136.
  1054.       email: kannan@oar.net
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063. Varadhan                                                       [Page 19]
  1064. -----
  1065.  
  1066. -=-
  1067. Kannan Varadhan,        1224, Kinnear Road,    +1 614 292 4137
  1068. Internet Engineer (OARnet)    Columbus, OH 43212    +1 614 292 7168 (FAX)
  1069.